Smoke Testing and Sanity Testing are important software testing techniques used to quickly determine whether an application build is stable enough for further testing and whether a particular change or functionality is working correctly. Both are generally performed before deeper levels of testing to reduce unnecessary testing effort and identify major problems at an early stage.
Smoke Testing focuses on checking the critical and major functionalities of an application to determine whether the build is stable for detailed testing. Sanity Testing is a focused testing activity performed after minor changes, bug fixes, or enhancements to verify that the specific functionality works correctly and that the related areas have not been obviously broken.
In Selenium automation, Smoke and Sanity Testing can be automated for web applications using Selenium WebDriver along with frameworks such as TestNG. JustAcademy's Selenium Automation Testing curriculum includes software testing fundamentals and types of testing such as smoke testing, along with Selenium WebDriver, TestNG, Page Object Model, cross-browser testing, regression testing, and automation frameworks.
Selenium Training Resource: JustAcademy Selenium Training
Course Demo Registration: Register for Selenium Course Demo
Smoke Testing is a preliminary testing technique used to verify whether the major and critical functionalities of a software build are working correctly. It is usually performed when a new build is received from the development team.
The main purpose of Smoke Testing is to determine whether the build is stable enough to proceed with detailed testing.
Smoke Testing is a high-level test performed on a new build to verify that the critical features of the application are functioning and the build is stable enough for further testing.
Suppose an e-commerce application receives a new build. Before executing hundreds of detailed test cases, testers may verify:
If these major functions are working, the build can proceed to detailed testing.
Modern applications can contain thousands of test cases. Executing all test cases on every new build is inefficient if the build itself has a major problem.
Smoke Testing provides an early indication of build stability.
New Application Build
↓
Install / Deploy Build
↓
Execute Critical Test Cases
↓
Check Major Features
↓
Build Stable?
↙ ↘
Yes No
↓ ↓
Detailed Reject Build
Testing / Report DefectsSanity Testing is a focused testing technique performed after specific changes, bug fixes, enhancements, or minor modifications to verify that the affected functionality is working correctly.
Unlike Smoke Testing, which generally evaluates the overall stability of a build at a high level, Sanity Testing concentrates on a narrower area of the application.
Sanity Testing is a focused testing process used to verify that a particular change or bug fix works correctly and that the related functionality is still behaving as expected.
Suppose the login password validation logic has been changed.
Instead of testing the complete application, the tester may focus on:
Sanity Testing helps testers quickly determine whether a specific modification has been implemented correctly.
| Feature | Smoke Testing | Sanity Testing |
|---|---|---|
| Purpose | Check overall build stability | Check specific functionality or change |
| Scope | Broad but shallow | Narrow but focused |
| Performed On | New build | Modified or corrected build |
| Focus | Critical application features | Specific affected functionality |
| Test Coverage | High-level coverage | Focused coverage |
| Detailed Testing | Not normally detailed | More focused on the affected area |
| Automation | Can be automated | Can be automated |
| Typical Result | Accept or reject build for further testing | Confirm the specific change is functioning correctly |
Smoke Testing and Regression Testing have different objectives.
| Smoke Testing | Regression Testing |
|---|---|
| Checks critical functionality. | Checks existing functionality after changes. |
| Usually broad and shallow. | Can be broad and detailed. |
| Usually performed on a new build. | Performed after changes, fixes, or enhancements. |
| Determines whether the build is testable. | Determines whether existing functionality remains unaffected. |
| Usually smaller test suite. | Usually larger test suite. |
| Smoke Testing | Retesting |
|---|---|
| Checks whether a build is stable. | Checks whether a particular defect has been fixed. |
| Tests critical application workflows. | Tests the previously failed scenario. |
| Can contain multiple critical test cases. | Usually focuses on a specific defect. |
| Performed on a new build. | Performed after a defect fix. |
A typical Smoke Testing process can be represented as follows:
Build Received
↓
Build Deployment
↓
Identify Critical Features
↓
Execute Smoke Test Cases
↓
Verify Major Workflows
↓
Analyze Results
↓
Build Accepted or RejectedThe development team provides a new build for testing.
The build is deployed into the appropriate test environment.
Testers identify the most important application workflows.
Critical test cases are executed.
If critical workflows work correctly, the build can proceed to detailed testing. If major functionality is broken, the build may be rejected for further testing.
Requirement / Bug Fix
↓
Build Received
↓
Identify Changed Functionality
↓
Identify Related Features
↓
Execute Focused Tests
↓
Verify Expected Behavior
↓
Analyze Results
↓
Proceed to Regression / Further TestingThe tester reviews the requirement, enhancement, or bug fix.
The specific module or functionality affected by the change is identified.
Only relevant test cases are selected.
The affected functionality and closely related functionality are tested.
If the change behaves correctly, further testing such as regression testing can be performed.
Smoke Testing is commonly performed when a new build is delivered to the testing team.
Consider an e-commerce application containing login, product search, product details, cart, checkout, payment, and order confirmation.
| Test Case | Expected Result |
|---|---|
| Open application | Application loads successfully |
| Login | User successfully logs in |
| Search product | Search results are displayed |
| Open product | Product details page opens |
| Add to cart | Product is added to cart |
| Open checkout | Checkout page opens |
| Logout | User successfully logs out |
Open Website
↓
Login
↓
Search Product
↓
Open Product
↓
Add to Cart
↓
Checkout
↓
Logout
↓
Build Stability ResultSuppose the development team modifies the shopping cart quantity functionality.
The tester does not necessarily need to execute the complete application test suite for this focused validation.
Smoke Testing is useful in Agile development because builds can be produced frequently during development and sprint execution.
User Story
↓
Development
↓
Build
↓
Smoke Testing
↓
Detailed Functional Testing
↓
Defect Fix
↓
Retesting
↓
Regression Testing
↓
Sprint Validation
↓
ReleaseSmoke tests can be integrated into CI/CD pipelines so that a newly deployed build is automatically checked before more extensive testing or deployment stages.
Developer Commit
↓
Source Control
↓
Build
↓
Deploy to Test Environment
↓
Automated Smoke Tests
↓
Test Results
↓
Pass / Fail
↙ ↘
Pass Fail
↓ ↓
Next Stage Stop PipelineAfter a new application build is deployed, automated Selenium tests can verify that the login page loads, login works, the dashboard opens, and the main navigation is available.
Selenium WebDriver can automate Smoke Testing for web applications. Selenium allows testers to interact with browsers and verify important application workflows.
Smoke Test Case
↓
Selenium WebDriver
↓
Browser
↓
Web Application
↓
User Interaction
↓
Application Response
↓
Assertion
↓
Pass / Failimport org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
public class SmokeTest {
public static void main(String[] args) {
WebDriver driver = new ChromeDriver();
driver.get("https://example.com");
driver.findElement(By.id("username"))
.sendKeys("[email protected]");
driver.findElement(By.id("password"))
.sendKeys("Test@123");
driver.findElement(By.id("loginButton"))
.click();
String title = driver.getTitle();
System.out.println("Application Title: " + title);
driver.quit();
}
}Suppose the login module has been modified. A Selenium Sanity Test can focus on the login workflow.
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
public class LoginSanityTest {
public static void main(String[] args) {
WebDriver driver = new ChromeDriver();
driver.get("https://example.com/login");
driver.findElement(By.id("username"))
.sendKeys("[email protected]");
driver.findElement(By.id("password"))
.sendKeys("Test@123");
driver.findElement(By.id("loginButton"))
.click();
String currentUrl = driver.getCurrentUrl();
if (currentUrl.contains("dashboard")) {
System.out.println("Login Sanity Test Passed");
} else {
System.out.println("Login Sanity Test Failed");
}
driver.quit();
}
}TestNG can be used to organize automated smoke test cases and execute selected tests.
import org.testng.annotations.Test;
public class SmokeTests {
@Test
public void loginSmokeTest() {
System.out.println("Login Smoke Test");
}
@Test
public void searchSmokeTest() {
System.out.println("Search Smoke Test");
}
@Test
public void cartSmokeTest() {
System.out.println("Cart Smoke Test");
}
}TestNG groups can be used to separate smoke tests from other test types.
import org.testng.annotations.Test;
public class TestSuite {
@Test(groups = {"smoke"})
public void loginTest() {
System.out.println("Login Smoke Test");
}
@Test(groups = {"smoke"})
public void searchTest() {
System.out.println("Search Smoke Test");
}
@Test(groups = {"regression"})
public void detailedCheckoutTest() {
System.out.println("Checkout Regression Test");
}
}This approach allows teams to execute only the smoke tests when they need a quick build validation.
import org.testng.annotations.Test;
public class SanityTests {
@Test(groups = {"sanity"})
public void loginValidation() {
System.out.println("Login Sanity Test");
}
@Test(groups = {"sanity"})
public void passwordValidation() {
System.out.println("Password Sanity Test");
}
@Test(groups = {"sanity"})
public void dashboardValidation() {
System.out.println("Dashboard Sanity Test");
}
}A Smoke Test Suite contains a small set of critical test cases designed to validate the basic health of an application.
| Module | Smoke Test |
|---|---|
| Login | Valid user can log in |
| Search | Search returns results |
| Product | Product details open |
| Cart | Product can be added |
| Checkout | Checkout page opens |
| Logout | User can log out |
A Sanity Test Suite is focused on a particular feature, module, enhancement, or bug fix.
| Change | Sanity Test |
|---|---|
| Login validation changed | Validate login scenarios |
| Password reset changed | Validate reset password flow |
| Cart quantity changed | Validate quantity and price calculation |
| Search filter changed | Validate filtering functionality |
| Checkout address changed | Validate address selection and checkout |
Smoke Testing is sometimes described as Build Verification Testing because it verifies whether the basic build is stable enough for further testing.
If an application cannot open the login page, there is little value in executing hundreds of detailed test cases. Smoke Testing identifies this type of critical problem early.
Sanity Testing is particularly useful after bug fixes.
Defect Reported
↓
Developer Fix
↓
New Build
↓
Sanity Testing
↓
Verify Fixed Functionality
↓
Verify Related Functionality
↓
Regression Testing
↓
Final ValidationSmoke Testing and Regression Testing can work together as part of a larger testing process.
New Build
↓
Smoke Testing
↓
Build Stable?
↓
Yes
↓
Functional Testing
↓
Bug Fixes
↓
Retesting
↓
Regression Testing
↓
Release ValidationThe smoke suite provides a quick initial check, while the regression suite provides broader validation after changes.
Assertions are important because simply executing browser actions does not prove that the application behaved correctly.
String expectedTitle = "Dashboard";
String actualTitle = driver.getTitle();
if (actualTitle.equals(expectedTitle)) {
System.out.println("Smoke Test Passed");
} else {
System.out.println("Smoke Test Failed");
}In TestNG, assertions can be used directly:
import org.testng.Assert;
import org.testng.annotations.Test;
@Test
public void dashboardTest() {
String expectedTitle = "Dashboard";
String actualTitle = driver.getTitle();
Assert.assertEquals(actualTitle, expectedTitle);
}Dynamic web applications may take time to load elements. Explicit waits can make automation more reliable by waiting for a specific condition.
WebDriverWait wait =
new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement loginButton =
wait.until(
ExpectedConditions.elementToBeClickable(
By.id("loginButton")
)
);
loginButton.click();Page Object Model, commonly called POM, separates page-specific locators and actions from test cases.
public class LoginPage {
WebDriver driver;
By username = By.id("username");
By password = By.id("password");
By loginButton = By.id("loginButton");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void enterUsername(String value) {
driver.findElement(username).sendKeys(value);
}
public void enterPassword(String value) {
driver.findElement(password).sendKeys(value);
}
public void clickLogin() {
driver.findElement(loginButton).click();
}
}LoginPage loginPage = new LoginPage(driver);
loginPage.enterUsername("[email protected]");
loginPage.enterPassword("Test@123");
loginPage.clickLogin();POM becomes particularly useful when Smoke and Sanity suites grow and many tests reuse the same application pages.
selenium-project/
│
├── src/test/java/
│ ├── tests/
│ │ ├── LoginSmokeTest.java
│ │ ├── SearchSmokeTest.java
│ │ └── CartSmokeTest.java
│ │
│ ├── pages/
│ │ ├── LoginPage.java
│ │ ├── HomePage.java
│ │ └── CartPage.java
│ │
│ └── utilities/
│ ├── DriverManager.java
│ └── TestData.java
│
├── testng.xml
└── pom.xmlConsider an online shopping application.
Login
↓
Search Product
↓
Open Product
↓
Add to Cart
↓
Checkout
↓
LogoutThis suite does not need to cover every possible combination of product filters, payment methods, addresses, or negative scenarios. Its primary purpose is to quickly determine whether the critical application workflow is functioning.
Suppose the payment confirmation page has been modified.
After successful sanity validation, the team may execute a broader regression suite covering other existing application functionality.
Smoke tests are well suited for early stages of a CI pipeline because they can provide quick feedback after a build.
Developer
↓
Git Commit
↓
CI Server
↓
Build
↓
Deploy
↓
Smoke Tests
↓
Smoke Passed?
↙ ↘
Yes No
↓ ↓
Continue Stop / Notify
Pipeline TeamSelenium Grid can be used when Smoke Testing needs to run against multiple browsers or environments.
| Browser | Smoke Test |
|---|---|
| Chrome | Login and checkout |
| Firefox | Login and checkout |
| Edge | Login and checkout |
This can help identify browser-specific problems early in the testing process.
Smoke Testing can be performed manually by executing a predefined set of critical test cases.
Automated Smoke Testing uses automation tools such as Selenium to execute predefined critical tests.
| Manual | Automated |
|---|---|
| Executed by tester. | Executed by automation script. |
| Requires manual effort. | Requires initial automation development. |
| Slower for repeated execution. | Faster for repeated execution. |
| Useful for exploratory checks. | Useful for stable repetitive scenarios. |
| Limited CI/CD integration. | Strong CI/CD integration. |
New Build
↓
Is this a major/new build?
↓
Smoke Testing
↓
Build Stable?
↙ ↘
No Yes
↓ ↓
Reject Detailed Testing
Build ↓
Change / Bug Fix
↓
Sanity Testing
↓
Function Correct?
↙ ↘
No Yes
↓ ↓
Report Regression
Defect TestingProject: E-Commerce Web Application
Create a Selenium-based Smoke Test Suite that validates the most important user workflow.
The complete critical workflow should execute successfully. If a critical step fails, the smoke suite should report the failure.
Project: Shopping Cart Enhancement
The development team has changed the shopping cart quantity functionality.
| Test Case ID | Scenario | Expected Result | Priority |
|---|---|---|---|
| SMK001 | Launch application | Application opens | High |
| SMK002 | Login | User logs in | High |
| SMK003 | Search product | Results displayed | High |
| SMK004 | Add product | Product added to cart | High |
| SMK005 | Open checkout | Checkout opens | High |
| Test Case ID | Scenario | Expected Result |
|---|---|---|
| SAN001 | Updated login validation | Correct validation displayed |
| SAN002 | Invalid password | Error message displayed |
| SAN003 | Valid password | User logs in |
| SAN004 | Dashboard redirection | Dashboard opens |
Testing environments can include development, QA, staging, and pre-production environments.
| Environment | Typical Testing |
|---|---|
| Development | Developer-level verification and basic testing |
| QA | Smoke, functional, sanity, regression testing |
| Staging | Release validation and broader testing |
| Production | Controlled post-deployment verification where applicable |
Smoke Testing can be used as an initial validation layer before more detailed release testing.
Release Build
↓
Deployment
↓
Smoke Testing
↓
Critical Functions Working?
↓
Yes
↓
Detailed Testing
↓
Regression Testing
↓
Release ValidationTeams can track basic metrics to understand smoke suite effectiveness.
| Metric | Description |
|---|---|
| Smoke Test Pass Rate | Percentage of smoke tests that pass |
| Smoke Test Execution Time | Time required to complete the suite |
| Build Rejection Rate | Frequency with which builds fail smoke testing |
| Critical Defects | Critical problems discovered during smoke testing |
| Automation Stability | Reliability of automated smoke tests |
Smoke Testing is a preliminary testing technique used to verify that the critical functionality of a build is working and that the build is stable enough for further testing.
It is performed to identify major build-level problems early and prevent testers from spending time on a build that is not stable.
Yes. Smoke Testing can be automated using tools such as Selenium for web applications.
Smoke Testing is generally broad in coverage but shallow in depth.
It is commonly performed when a new build is available for testing.
Sanity Testing is focused testing performed after a change or bug fix to verify that the affected functionality works correctly.
It helps quickly verify whether a particular change or fix behaves as expected.
Yes. Stable sanity scenarios can be automated using Selenium and a test framework such as TestNG.
Sanity Testing is generally narrow and focused on a particular area.
Question: A new build has been deployed to the QA environment. What testing should be performed first?
Answer: A Smoke Test Suite can be executed first to verify that critical application functionality is working and the build is stable enough for detailed testing.
Question: A login defect has been fixed. What testing would you perform?
Answer: Focused testing of the login functionality can be performed as Sanity Testing, followed by broader regression testing when appropriate.
Question: The cart quantity calculation has changed. What should be tested?
Answer: The changed quantity calculation and closely related cart functionality should be verified through focused Sanity Testing.
| Smoke Testing | Sanity Testing |
|---|---|
| New build validation | Change/fix validation |
| Broad and shallow | Narrow and focused |
| Critical application features | Specific affected functionality |
| Checks build stability | Checks change stability |
| Usually executed before detailed testing | Usually executed after a specific change or fix |
| Can be automated | Can be automated |
| Can be integrated with CI/CD | Can be integrated with CI/CD |
Development
↓
Build Created
↓
Deployment
↓
Smoke Testing
↓
Build Stable?
↙ ↘
No Yes
↓ ↓
Defect Functional Testing
Report ↓
Change / Fix
↓
Sanity Testing
↓
Function Correct?
↙ ↘
No Yes
↓ ↓
Defect Regression
Fix Testing
↓
Release TestingAssignment: Create an automated Selenium Smoke Test Suite for an e-commerce web application.
Assignment: Automate Sanity Testing for a modified login module.
After completing these Smoke and Sanity Testing notes, learners should be able to:
For structured Selenium automation training covering Selenium WebDriver, TestNG, Page Object Model, automation frameworks, cross-browser testing, regression testing, and practical projects, visit the JustAcademy Selenium Training page.
Click Here to Explore JustAcademy Selenium Training
Click Here to Register for Course Demo
Smoke Testing and Sanity Testing are important testing techniques used to provide quick feedback about an application's stability and changes.
Smoke Testing focuses on critical application functionality and determines whether a new build is stable enough for further testing.
Sanity Testing focuses on a specific change, enhancement, or bug fix and verifies that the affected functionality works correctly.
In Selenium automation, both types of testing can be implemented using Selenium WebDriver, TestNG, assertions, Page Object Model, explicit waits, reusable utilities, and CI/CD integration.
Smoke Testing
↓
Build Stability
↓
Detailed Testing
↓
Changes / Bug Fixes
↓
Sanity Testing
↓
Regression Testing
↓
Release ValidationUnderstanding the difference between Smoke and Sanity Testing helps testers select the appropriate testing scope, reduce unnecessary execution time, identify problems earlier, and build maintainable Selenium automation suites.
